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REMARKS 

Claims 12 and 14-18 are pending. The Office has rejected the claims as follow?: claims 
12 and 14-1 8 are rejected under 35 USC 102(e) as being anticipated by Wharton 
(US2005/00276 10). The undersigned respectfully submits that in view of the argumer ts 
presented herein, the pending claims are allowable over the art cited. 



Re j ection of claims 12 and 14-18 as being Unpatenable Over Wharton 

Independent claim 12 contains the following language and independent claim 1 8 

contains similar language in means format: 

12. (Previously Amended) A method for conducting mobile commerce 
comprising: 

transmitting in a first language a request message for 
merchant website information from a mobile device; 

receiving the request message in the first language at a 
platform and identifying the first language; 

translating the request message at the platform from the first 
language to a second language that is recognizable by a merchant website; 

communicating the translated request message in the second 
language from the platform to the merchant website; 

receiving at the platform the requested merchant website 
information from the merchant website in the second language; 

recognizing the second language at the platform; 

parsing the requested merchant website information in the 
second language into translatable pieces; 

translating the translatable pieces of the requested website 
information into the first language so as to form a reply message containing 
the requested merchant website information in the first language; and 

transmitting the reply message to the mobile device; 

transmitting a purchase request in response to the reply 
message in a first language to the platform; 
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receiving the purchase request in the first language at a 
platform and identifying the first language; 

translating the purchase request at the platform from the first 
language to a second language that is recognizable by the merchant website; 

communicating the translated purchase request in the second 
language from the platform to the merchant website; 

receiving at the platform a purchase request response from tie 
merchant website in the second language, wherein the purchase request response 
includes a payment authorization request; 

forwarding the purchase request response in this second language 
from the platform to a payment authorization system for a payment authorization 
response; 

receiving at the platform, the purchase request response, including 
the payment authorization response, in the second language from the payment 
authorization system; 

parsing the purchase request response in the second language into 
translatable pieces; 

translating the translatable pieces of the purchase request response 
into the first language so as to form a purchase request response in the fh-st 
language; and 

transmitting the purchase request response in the first 
language to the mobile device. 



The undersigned has reviewed the Wharton published application, particularly, Figures 1 ioid 4 and 

paragraphs [0009], [0010], [0046], [0051] and [0053] which are set forth below. 

[0009] Some of the disclosed systems provide an E-Commerce system and 
method for providing a single, unified back-end transaction processing system 
coupled to a plurality of vendor commerce systems through an E-Commerce 
portal. The vendor commerce systems may include local catalog, and customer 
data, as well as a local shopping basket and local business rules that are specific to 
a particular vendor. The unified back-end processor may include software 
programming for interfacing to numerous back-end processing systems, such as 
payment verification, accounting/billing and order fulfillment systems. Also 
optionally included at the back-end processor are a variety of data storage devices 
for storing merchant-specific and customer-specific transaction processing 
information, and also a global shopping basket for storing transaction order items 
that are generated during a customer interaction with the pluralily of vendor 
commerce systems associated with the E-Commerce system. A ^unique payment 
proxy system for interfacing the back-end transaction processing system to a 
plurality of payment verification systems may also provided. 
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[0010] An exemplary E-Commerce system is further disclosed tliat includes a 
plurality of vendor commerce systems; a plurality of back-end processing systerrs 
for processing transaction requests generated by the plurality of vendor commerce 
systems; and a transaction processor coupled between the plurality of vendor 
commerce systems and the plurality of back-end processing systems, wherein the 
transaction processor includes a global shopping basket for storing transaction 
information generated by the plurality of vendor commerce systems, and a back- 
end processor interface for processing and routing the stored transaction requests 
to the plurality of back-end processing sysfems. 
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[0046] After the ICC transaction processor 12 has obtained the merchant-specific 
rules, at step 98 it queries the customer database 58 in order to obtain any 
customer-specific transaction processing rules. Although these customer-specific 
rules may take a variety of forms, these rules will generally include a customer 
account number (for verification purposes) and one or more rundnie scripts for 
providing interactive feedback about the processed transactions to the customer's 
system 42. For example, the customer system 42 may be operating some type of 
enterprise system software coupled to a purchasing system for tracking purchased 
items. In this situation, a runtime script can be stored at the customer database 5U 
and processed by the ICC transaction processor 12 at the time that relevant 
transaction items are processed. In this manner, information regi;irding actual 
purchases that are committed by the system 1 0 can be transmitted back to the 
customer's system 42 in a format that is compatible with the customer^ 
purchasing software system. Other types of runtime scripting algorithms could 
certainly be implemented between the ICC transaction processor 12 and the 
customer's system 42. 

[0051] Operationally, the exemplary payment proxy 16 works as follows. At step 
1 (FIG. 4), the ICC transaction processor 12 (or other E-Commerce system) sends 
a particular transaction for payment authorization. This information is 
communicated to the payment proxy interface 60 using a software programmed 
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API that provides a universal interface to E-Commerce systems. As with the othor 
communication APIs noted above > this software programming can take a variety 
of different formats, and may be programmed using a variety of different 
programming techniques and languages, which would be apparent to one of skill 
in this field. The importance of the interface APf s is that they provide a common 
language that can be provided to other E-Commerce systems and merchants to 
enable them to interface their systems to the framework shown in FIG. 1 and the 
payment proxy system 16 shown in FIG. 4. The interface to the payment proxy 16 
might utilize HTTP or HTTPS packets, although many other interface technique.; 
could be used, such as, for example, CIP, Sockets, or RPC, to name but a few. 

[0053] Having determined how to process the particular transaction authorization 
request, the payment proxy 1 6, at step 3, then sends the transaction to the proper 
paymenl connection module 64. The payment connection modules 64 each 
provide interface programming for instructing the payment proxy 16 how to 
communicate with the plurality of payment verification systems 22, 24. At step 
the transaction authorization is routed to the proper payment verification system. 
The payment processor then authenticates the transaction request at step 5 and 
transmits back to the payment proxy system 1 6 a failure code (indicating that the 
transaction was not iauthorized), or an "auth-code" (indicating thai the transaction 
was authorized.) The payment proxy 16 then routes the code back to the ICC 
transaction processor 12 (or other E-Commerce system) at step 6, which, at step 7, 
then reacts to the code by, for example, sending a message to the customer 
indicating whether the transaction has failed or has been authorized. 



The undersigned does not find disclosure of at least the bold limitations of claim 12 in Wharton. 
Importantly, Wharton does not describe a mobile device. And Wharton does not describe a 
platform for receiving/sending request messages or other communications from/to a mobile 
device. Accordingly, all communications originating from the mobile device as claimed and 
responsive to communications from the mobile device are not disclosed in Wharton. 

Wharton is directed to a system and method for facilitating e-commerce (as distinguised 
from mobile commerce). The path of communications described in Wharton is: customer — > 
merchant -> transaction processor. Whereas the pending claims describe, generally, the 
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following path: customer/mobile device -> translation platform -> merchant -> translation 
plalfomi -> customer — > translation platform In Wharton, the customer communicates 

directly with the merchant and does not go through a common translation platform. Accordingly, 
it is clear that Wharton does not disclose the method steps of claim 1 2 or the means for 
facilitating these functions as set forth in claim 18. 

Additionally, Wharton does not contemplate wireless communications beyond mere 
recitation of a implementation on a "wireless data network," offering no further enabling 
description For this implementation. Wharton is not enabling for and does not disclose the 
wireless first language limitation or particular languages that could be used. Accordingly, claims 
14 and 15 are not anticipated by Wharton for this additional reason. 
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CONCLUSIONS 

For the reasons set forth herein, the undersigned submits that the claims are allowable 
over the cited ait and respectfully requests a notice of allowance to this effect. Should the Office 
feel that contacting undersigned will expedite prosecution, please do not hesitate to do so at the 
number provided below. 



Respectfully submitted, 



Date: 2/26/07 

KILPATRICK STOCKTON LLP 
607 14 th Street, N.W., Suite 900 
Washington, D.C. 20005 
(202) 508-5846 

T0t)91/24&312 
WSHUS0 1:208291 



/Dawn-Marie BevRez. No. 44.442 / 
Dawn-Marie Bey 
Registration No. 44,442 
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